The IEEE 802.21 standard provides a uniform set of functionalities that help enable and enhance handovers across different link layer technologies. In particular, IEEE 802.21 defines a media independent handover (MIH) client which resides in communications entities of several wireless systems capable of supporting inter-system handover.
At a high level, the enhanced handover capability involves an upper layer MIH user which can communicate with a MIH client, either locally or remotely, over a transport medium. The MIH client, in turn, interacts with link-layer devices. An 802.21 MIH client is disclosed in U.S. patent application Ser. No. 11/862,963, filed on Sep. 27, 2007.
The purpose of the 802.21 MIH client is to allow efficient software implementation of handover between different technologies (e.g. wireless broadband (WiBro) to universal mobile telecommunications system (UMTS)). The MIH client also enables automatic inter-technology mobility, both at Layer 2 and Layer 3, reduces handover interruption time, and provides quality of service (QoS) optimization across technologies.
FIG. 1 is a block diagram of an example 802.21 MIH client architecture for performing a handover from a WiBro network to a wideband code division multiple access (WCDMA) network. A wireless transmit/receive unit (WTRU) 100 may include an IEEE 802.21 (e.g., WiBro, worldwide interoperability for microwave access (WiMAX) or the like) modem 110, a WDCMA modem 120, an MIH client (MIH middleware) 130, and an upper layer 140. The WTRU 100 may also include one or more other components that are not illustrated in FIG. 1 for purposes of clarity. The upper layer 140 may include an application layer 150, (such as instant message, web browsing, or the like), a control protocol layer 160 (that includes modules such as a session initiation protocol (SIP) client 162, a Mobile Internet protocol (MIP) client 164, a dynamic host configuration protocol (DHCP)/domain name system (DNS) module 166, or the like), a transport layer 170, (such as a user datagram protocol (UDP) layer, a transmission control protocol (TCP) layer, a stream control transmission protocol (SCTP), a datagram congestion control protocol (DCCP), or the like), an IP layer 180, and an operating and maintenance (O&M) entity 190. The WiBro modem may include a WiBro physical layer 112 and a WiBro medium access layer (MAC) 114. The WCDMA modem may include a physical layer 122, an access stratum (AS) layer 124, and a non-access stratum (NAS) layer 126. The commands and information from the MIH client 130 to the WiBro modem 110 and the WCDMA modem 120, or vice versa, may be communicated via 802.21 service access points (SAPs) 118, 128 that perform mapping functions for the WiBro modem 110 and the WCDMA modem 120.
For example, a method for implementing software interfaces between the MIH client 130 and other entities in the WTRU 100 is provided. The software interfaces provide the MIH client 130 with mechanisms to receive information about the WiBro and WCDMA links, control the WiBro modem 110, the WCDMA modem 120 and other components of the WTRU 100 for inter-technology handover, discover an MIH server and IP multimedia system (IMS) network nodes through DHCP or domain name system (DNS), trigger Mobile IP to perform IP handover, send or receive MIH messages over TCP/UDP, and allow the O&M entity 190 to be able to control the MIH entity 130.
The radio interface layer (RIL) concept is disclosed in Microsoft Corporation U.S. Pat. No. 6,826,762, dated Nov. 30, 2004. A RIL is used to provide access to cellular functionality for any component in a wireless device (e.g., a phone, personal digital assistant (PDA), etc.). The RIL is an application program interface (API) set providing a level of abstraction between the radio on a cell phone and the software of the wireless device. Without the RIL, each component would have to understand how to communicate to the radio directly. The RIL was created to reside between the radio and the applications running on the wireless device.
FIG. 2 shows a RIL architecture. The RIL is composed of the following: multiple instances of RIL Proxy 235 that are hardware-independent, and one RIL Driver 240 that is hardware-specific. As shown in FIG. 2, the RIL architecture may also include a Subscriber Identity Module (SIM) module 205, an emergency module 210, a StingTSP module 215, a Wireless Application Protocol (WAP) module 220, a short message service (SMS) module 225, a data stack module 230, a Virtual Serial Port (VSP) module 250, and radio hardware 245.
Symbian and Linux application frameworks, such as Qtopia, Android and LIMO for example, use a telephony server to interface with communication devices like a cellular modem, wireless local area network (WLAN), WiMax etc. The telephony server establishes the network connections as requested by a user and maintains the connection. Otherwise, connections are set up based on static configurations.
Mobile devices often include more than one communication module and are able to setup simultaneous connections. MIH technology ideally fits in this application framework and improves the user experience by providing seamless handover across various radio access technologies.
FIG. 3 is an example block diagram showing the architecture of the telephony application framework 300. The telephony server 310 is responsible for handling circuit switched calls over a cellular modem or voice over internet protocol (VoIP). The network stack 320 is responsible for handling packet switched sessions over various network technologies, such as 2.5 G, 3 G, WLAN, etc.
The telephony server 310 is functionally split into three main functions. These functions are the user interface and APIs to applications, the call processing functions for various call types, e.g. global system for mobile communication (GSM), VoIP, etc., and the device management functions. Each function will now be discussed in turn.
The user interface (UI) functional block 330 provides an API, for example for Qtopia applications, and a graphical user interface (GUI) to obtain access to the telephony server. Examples of Qtopia applications include a phone dialer and a SMS/MMS client, etc.
This functionality is generally implemented using a UI widget. A UI widget is an object used to hold data and present an interface to the user. A UI widget is a combination of state and procedure. The UI widget maintains state information about different applications. This is what allows a user to navigate across various screens such as an active voice call session, a SMS session and a browser session running in parallel. The UI widget runs as a server and is brought up during the system startup phase and is always available to accept telephony requests from applications. The UI widget uses the call processing module API to initiate a new call, disconnect a call, etc.
The call processing module 340 accepts requests for a new call, requests to send a SMS/MMS from the UI widget, and provides indications about the call such as ringing, call accepted, etc. to the UI widget.
The call processing module 340 uses the services provided by device management module 350 to dial a call, send SMS etc. It uses the indications provided by device management module 350 such as call state, device state, arrival of a new message, etc. to support call processing functions.
The call processing module 340 consists of three main functional components. These components are the policy manager 360, the call handlers 370 for different call types, e.g. GSM, VoIP, etc., and general indications and services 380, such as subscriber identity module (SIM) access, phone book update, etc.
The policy manager 360 and call handler function 370 service only voice and circuit switched data (CSD) calls. The policy manager determines the call handler, such as GSM handler or VoIP handler, to be used to handle voice or CSD calls. The UI widget sends call requests to the policy manager and specifies the call type. Based on the call type, the policy manager decides which call handler to use for servicing the call request. The policy manager maintains a list of call handlers during system startup and initialization.
The call handler accepts call requests, such as create a new call from the policy manager. It directly notifies the UI widget about the call state. Call handlers handle each call separately and maintain the call state. It also maintains the state of the device. The call handlers use the service provided by the device management module to complete the call request. For example, it may request to dial a number if allowed by the call state machine. The call handler receives indications related to call state, such as waiting for an answer, modem is ready, or arrival of a new incoming call from the device management module. The call handler uses these indications to update an existing call state machine or create a new call state machine.
Other services, such as short message service (SMS), multimedia messaging service (MMS), contact and phone book update are handled by the general indications and services functional block 340. The general indications and services functional block 340 is responsible for accepting requests from the UI widget for services such as sending SMS, performing a phone book update, accessing a SIM, etc. After processing these requests, indications about the state are sent to the UI widget. Other autonomous indications, such as signal strength and battery power, are collected by this module and forwarded to the UI. The general indications and services function 340 uses the device management function to implement the services such as sending SMS, reading SMS, and updating the SIM phone book. It receives indications about the signal strength and battery power from the device management module 350.
The device management module 350 provides access to the device for functions such as dialing numbers, checking network registration, collect signal strength, etc. It maintains the device state based on the requests and the response. This state information is sent to the call processing module 340 to update the call state machine. The device management module 350 consists of two main functions, namely the phone server 352 and the device services (which include, e.g., a modem service provider 354 and a VOIP service provider 356).
The phone server 352 is the main interface to the device management module 350. All service requests from call processing modules go through the phone server 352. During device initialization, the phone server 352 starts up all services. The services that are started successfully are maintained by the phone server 352. The phone server 352 uses this information to dispatch requests to the proper device service 354, 356.
The device services are a collection of independent actions performed on a device. For example, modem service consists of tasks like call handling, pin management, network registration, SIM phone book access and indication handler like signal strength, battery power, etc. for the cellular modem. These services work synchronously with the client functions in the call processing module 340. The phone server dispatches the service request from call processing modules 340 to device services 350. The call processing modules 340 and general indications and services functions 380 receives notification about the state of the call and indications such as new call, new SMS etc. The device service 350 interfaces with the actual device through device driver interface or special mechanisms such as attention (AT) command interface for cellular modems.
The network stack 320 is responsible for managing data sessions to support data applications like MMS, browser, etc. over data links such as 2.5 G, 3 G, WiMax or WLAN. Most data applications use session layer protocols 325 such as hypertext transport protocol (HTTP), session initiation protocol (SIP), and Mobile IP (MIP). These protocols are part of the network stack and follow standard implementation. These protocols use sockets and transmission control protocol/user datagram protocol (TCP/UDP) for transport. The socket service 335 is provided by the operating system (OS). The data link layer connection is managed by the network management module 345. Once the network management function sets up the data link layer, sockets can use it for data transport.
The network management module 345, is responsible for powering up and activating devices, registering with the network etc. It maintains the current state of a network interface. It is very similar to a connection manager functionality for static handling of Layer 2 connections and consists of the network server 346, the device manager 347, and the network manager 348. A Layer 2 connection is a combination of a device manager entity and a network manager entity. A device may be combined with one or more network entity. This combination is defined as network interface. The combinations are static and pre-configured.
The network server 346 provides functions for starting/stopping of network interfaces. It allows managing of existing network configurations. This is useful because applications can influence the connectivity state of a network interface. The network server synchronizes network interface operations across all applications. The client applications request network operations via the network server. The network server 346 will choose and load the appropriate network plug-in (software component specific to the device and network operation) based on the configuration handle (pointer to configuration parameter and configuration script). The client applications are notified about the network interface state.
The device manager 347 consists of device entities which are Layer 2 function wrappers such as point to point protocol (PPP) wrapper, and WLAN interface wrapper, etc., which provide a complete interface package with the application framework. The device manager manages the connectivity state of the device like on, off, transferring data, idle etc. The device manager is always associated with a configuration file which serves as an identifier/handle for a particular device. The network server 346 uses the configuration handle provided by the device entity to load a plug-in. The information about the device state is used to handle network interface requests.
The network manager 348 consists of various network entities which are wrapper functions to obtain network information and monitoring of network connection, for e.g. if the device is camped and registered with a GPRS network, available WLAN networks, etc. The network manager 348 provides this information to network server 346 to handle network interface requests.
The RIL and the telephony server described above lack the capability to support inter-system handover across different radio access technologies. As various communication networks and devices are becoming common in a phone platform, this feature is becoming necessary for multi-mode devices. Therefore adding 802.21 MIH functionality to a RIL or a telephony server would be desirable to allow an apparatus, such as a PC, laptop, cell phone, etc., to support inter-system handover across different radio access technologies.